Quote from nacim :

What's the use of the "CPU generated sky" ? Is it used to generate the ambient Spherical Harmonic or something like that ? Can't you reuse the GPU skybox, downsample it and upload it back to CPU ?

Yes, the CPU sky is for:
- ambient lighting spherical harmonic (for directional ambient lighting)
- maximum brightness value (needed before the GPU sky is generated - see below)
- average sky colour (I'm trying to move away from any uses of this)

The GPU sky can still be stored as a 32-bit SRGB texture, doesn't need to be 64-bit HDR if I know the maximum value (from the CPU) before it is generated on the GPU. Each pixel is then multiplied by (1.0 / max_brightness) so the sky uses the full 24-bit range of colours.

I'd sometimes like to be able to generate things on the GPU and read the texture back into system memory for analysis by the program, and I do this, not in realtime, in a few places:
- baked ambient and artificial lighting render
- path-based echo map
- path-based ambient lighting render for cars (called 'lightmap' in LFS)
- path-based occlusion test (called 'optimiser' in LFS)
- calculating average colours from textures

But as far as I know, reading back the texture from GPU to CPU will always cause a small glitch or hesitation, because the CPU must stop and wait, when it calls GetRenderTargetData, until the GPU is ready to send the data. I'm not sure if this is the case with later versions of DirectX - I think later versions are better for getting data back from the GPU because of compute shaders and so on. But I think this is a limitation with DX9 so I've avoided using that in real time situations. Anyway the CPU sky at 64x64 only takes 3 milliseconds in the debug build, and as it's on that separate thread there is no glitch at all, so I think it's quite good now. The lighting system judges that the sun has moved enough to need a new sky, asks the CPU sky thread to make a new sky, then when the CPU sky is generated a few ms later, the main thread tells the GPU to generate the new sky (seems to take no time at all).

Last edited by Scawen, Thu 14 Nov 2019, 10:18. Reason : typo

In the interests of explaining how development goes...

Warning, totally technical and not interesting for most people!

Most of the day was on restructuring the generated sky system a bit and removing some old code that is no longer needed so that yesterday's test has now become proper code to stay instead of being rapidly hacked in for test purposes. Although generating the sky on the GPU instead of the CPU, which is much faster, there was still a quite perceptible glitch long enough to cause a click in the sound each time a new sky was generated - that can be about once every 20 seconds around sunset / sunrise. The click was in my debug version of LFS and might not have happened in the release build but it's best to make it glitch free in the debug version, then it's sure to be OK in the release build, and also won't annoy me all the time while developing.

The glitch turned out to be because I started a new thread to generate the sky each time. A 'CPU sky' still needs to be generated for reasons related to lighting (in addition to the GPU sky) but now the CPU sky can be much smaller in size because it is not for direct display. Still, it's good to use a separate thread to do it to make use of our multiple core CPUs. The solution to the glitch was to have a sky generation thread running the whole time, just waiting for the command from the weather system to generate a new sky texture when required. It turns out that starting and stopping threads is quite expensive in debug builds.

Quote from Scawen :

There are still some bright pixels around I can look into but they aren't causing random blooms.

While testing the updated sky I was driving around South City at sunset and started looking into the remaining white pixels, now that the worst offenders were cured by bounding the fog exponential. I applied the _centroid interpolation modifier to various inputs to the pixel shader until I located the one that was causing the white pixels. It turned out to be the ambient lighting data from artificial lights. Now I can drive around South City or visit those camera locations at Blackwood without seeing any bright pixels at all.

So, a good day's work, though not the sort of thing that sounds very exciting to most people.

Quote from MandulAA :

I recreated the red pixels on my GTX 1060 3GB... I saw some strange flicker on the railings on the right as well, while the camera was stable and I didn't move it...

Thanks for the test. In free view mode the camera continues to move tiny amounts because of the camera smoothing system, so this can cause flicker if there's something prone to flickering in the view. I see on some of the railings what looks like a missing line that is sensitive to camera positions, which I think is related to unshared edges, probably due to triangle sub-splitting for the vertex lighting system. These artifacts seem to be more common with MSAA. I'm getting a lot of them (apparently missing lines) in the distance (near the red pixels) if I switch smoothly between two stored views (at the /cp locations above).

Quote from Rejekt :

Seems like that with MSAA pixel shader is ran only once at pixel center and the result is duplicated for all subsamples. So it could be that the pixel center doesn't pass the depth test, but some subsample does and that then proceeds to write the PS results computed with negative z of the pixel center...

Thanks for the info and link. I searched for the centroid semantic mentioned there and learned about the 'centroid interpolation modifier'. In shader model 2 and 3, the modifier can be added to the TEXCOORD semantic.

I did that and it made the red pixels disappear!

Exact description: In the VS_OUTPUT structure in the test shaders (pixel and vertex) I changed the line:
float FOGTEST : TEXCOORD1; // TEST
to:
float FOGTEST : TEXCOORD1_centroid; // TEST

So now the value of FOGTEST is calculated at some point within the triangle instead of outside the triangle, so avoiding the extrapolation problem that caused the 'unexpected' values.

Quote from Dygear :

My dash in the 2018 Hyundai Elantra adjust based on ambient light level. There is a light sensor in the center of the dash all of the way forward so that it's right under the bottom of the windshield. It gives it enough light, but puts it mostly out of the view of the driver and passengers.

Thanks, I'm going to try and see if my car has one of these. I know it adjusts the radio volume as I go faster which is conceptually similar.

Quote from Bose321 :

You said something about the calculation of fog, does that mean that's also coming in a new patch? (or is it already included? Haven't played LFS for a while).

There's already fog in public LFS but it is linear. The new version has exponential fog which is closer to reality. I'm not talking about thick fog, just the normal slight visibility reduction due to distance.

Anyway here's another couple of pictures. Note, Eric hasn't worked on the lighting in this version of Blackwood, it's just my test version with the lights switched on and things aren't really balanced correctly yet.

We are really far from a test version yet!

On my side there is still work to do on the graphics. I'm working on a bloom effect right now. I still need to improve the baked lighting rendering system to reduce some ugly vertex lighting issues you don't see too much of in my well-placed screenshots.

Then I still need to work on the physics and improve the security of the master server protocol.

Meanwhile Eric is continuing with South City, and still needs to finish Kyoto and update Fern Bay.

emiljensen2: TRM.13 found the reason for the crash. It crashes if "fixed foveated rendering" is enabled.
https://www.lfs.net/forum/post/1951489#post1951489

EDIT: If it's easy to do a quick test, I'd be interested to know if the same thing happens on your computer.

Last edited by Scawen, Sun 3 Nov 2019, 15:06.

TRM.13: I've moved our discussion about your crash into a separate thread in the bug reports section. That's because it's quite a long discussion now and isn't really related to the test patch (although I'd like to fix it in a test patch).
https://www.lfs.net/forum/thread/93703

OK, the stop and go bug should be fixed in test patch U9.

Also the display now alternates between the flags and the RCM or penalty message.

Download: https://www.lfs.net/forum/thread/93185

Test Patch U9 is now available.


- When LFS is set to close the reason is logged to deb.log file

TRM.13: please try to enter VR and then as soon as it goes wrong and LFS closes, please attach the deb.log file

- Live telemetry is available in a new customisable OutSim packet

Programmers: https://www.lfs.net/forum/thread/93701

- Yellow and blue flags now alternate with RCM or penalty message
- FIX: Stop-go penalty caused car to get stuck in custom pit stop


Download: https://www.lfs.net/forum/thread/93185

Hello programmers.

Detailed live telemetry is now available in a new customisable OutSim packet.

It is a combination of the RAF data and OutSim data. If this might be useful to you, I'd like to hear if there is any more information you would like to receive or any problems you see with this system. It is a first test in this test patch so please expect it to change.

The position of the car is the location of the reference point described in the CAR_info specification.

Enable detailed OutSim by setting the OutSim Opts value in cfg.txt
All extra data can be switched on with the value ff
The new data is documented in the attached header file OutSimPack.h

Download U9: https://www.lfs.net/forum/thread/93185

Maybe I need to add some logging in a test patch, so any reason for starting the exit process is logged as a line in deb.log.

For now, I just wondered what would happen if you start LFS in VR mode. You can do that by creating a shortcut to LFS.exe then add the command line /vr=openvr

So for example the Target line in shortcut properties might be:
C:\LFS\LFS.exe /vr=openvr

Quote from loopingz :

Hi there,
How can I map F8 (and space) to a button?
It might even be interesting to map a button to switch from 2D to 3D and vice versa.
I am noob at vr with 3 laps... So it might be stupid question.

In Options - Controls screen, CTRL+ or ALT+ tab:

You can assign the text /vr reset to the wheel button, to replicate F8.
And assign the command /press space to map the space key to a button.

Let me know if that's not clear.

Quote from mbutcher :

I wanted to make a thread about being able to customize the mapping for the VR Click (currently space). Every time I'm typing while leaning over my wheel I'm accidentally pressing OK, Cancel or special characters on the "T" text entry window because I'm pressing space to start a new word. To avoid it I have to deliberately look down while typing which is annoying during a situation where you need to focus on the road and type.

I won't get the VR headset out for a test right now, but I think you are saying that when the text box is visible, the cross hairs are also visible and the space key can then perform one of two functions. Either adding a space character to the text, or performing a 'click' if the cross hairs are over a button, which happens unexpectedly while typing unless you are careful about where you are looking. That does sound quite annoying.

I will try to remember this, I wonder if maybe there could be some kind of solution, without needing to reassign the space bar.

Thanks for the Valve Index feedback. I also have heard from a few other people that it was working fine. I guess you are using the test patch as I see you posted there.

I understand there is the frame rate mismatch. I'm interested to know if you think LFS looks better at 120Hz than at 90Hz.

My understanding is this:

90Hz: there is a 1/100th sec glitch forward every 1/10th of a second (a physics frame is missed 10 times per second).

120Hz: there is a tiny pause every 1/20th of a second (the same physics frame is drawn twice, 20 times per second).

I think these two cases would have a different appearance. Someone said that 120Hz looked better.

EDIT: This was for a test patch in the 0.6 era

For racers who have a Direct Drive wheel, Test Patch U7 has some new settings that allow you to remove a notchy force feeling and receive force updates with the minimum delay. And there is no longer a reason to use frame rates above 100 fps.

For OSW wheels the recommended settings are:

FF Steps -> 10000 (for max resolution allowed by DirectInput)
FF Rate -> 100 Hz (allows FF updates to match LFS physics rate)

I am interested to know if these are the best settings for all direct drive wheels. And to allow for the possibility of automatic presets, it would be useful to know the exact name of your wheel as it appears in LFS (see attached screen shot).

EDIT - test patch download link removed - all these updates are in the latest official version

The update does allow better settings for ordinary geared wheels too, but it is not recommended to go for the maximum. The default settings (Steps 400 Steps / Rate 50 Hz) may be all you need.

Last edited by Scawen, Thu 16 Jun 2022, 16:35.

As the Fanatec is direct drive, have you tried the new settings in the test patch?

For OSW wheels the recommended settings are:

FF Steps -> 10000 for max resolution allowed by DirectInput
FF Rate -> 100 Hz allows FF updates to match LFS physics rate

Thanks for the feedback, good to hear the patch solves the update problems.

For the OSW you should get Test Patch U7 and use the following settings:

Options - Controls screen:
Axes / FF tab:

FF Steps -> maximum
FF Rate -> maximum

Test Patch U7:

Force Feedback:

New settings are available under Axes / FF in Options - Controls
FF Steps maximum value is now 10000 (the maximum in DirectInput)
FF Rate is now controlled by a user setting (25 / 50 / 100 Hz)

VR:

Names over cars could fade differently in each eye in Pimax headset

Misc:

Gearshift debounce maximum setting restored to 200 ms (default 20)
More translations updated - thank you translators!

Download: https://www.lfs.net/forum/thread/93185

Thanks, I've added this to my test patch notes. To be clear, the stuck bug is not specifically related to open configs, but to the use of a custom pit stop point.

Quote from Vision73 :

Hi,
I usually drive with VR-set up but right now I don't have any.

I remember 18 months ago when I purchase my Samsung CHG90 49" Curved 32/9 Ultra Wide Monitor (3840 x 1080) that I never succeed to setup LFS correctly, today I tried again, no success, what ever I do or try.

I don't have any problems with other driving games, example with iRacing I can use 1 or 3 monitor setup or Dirt Rally with one monitor.

Can anyone help me with this ?

What is the problem you are having, can you describe what you are seeing, compared with what you should be seeing?

Quote from Dygear :

What's really insane about the VR code is that Scawen did it without ever having a headset himself.

I remember those times! That was only for the DK1 though, I ordered a DK2 as soon as orders opened. I did use all the tricks like coding for 3D anaglyph glasses at the same time and there were a lot of people who could test on 3D TV. I also had a Vuzix VR which didn't really work but could view stereo static images for a few seconds before it overheated, so I could do a lot of debugging before asking community members to check the output with VR distortion.

Thanks, now I understand your problem is different as the switch oscillation is not only at the start and end. So I'll revert to 200ms for the maximum in the next test patch.

Quote from KeiichiRX7 :

Any way we can get that debounce option for other controls, like up down left and right? Using the rotary dial on my g29 seems.to always yield 2 presses, milliseconds apart, makes it tricky to fine tune pit settings, or toggle whether I want damage repaired

The gearshift debounce setting now applies to all controller buttons in Test Patch U6:
https://www.lfs.net/forum/thread/93185

Test Patch U6:

Changes from 0.6U5 to 0.6U6:

Gearshift debounce setting now applies to all controller buttons
Reduced maximum value of gearshift debounce to 100 ms (default 20)
FIX: Memory leak related to threads (most often for skin download)
More translations updated - thank you translators!

Download:

https://www.lfs.net/forum/thread/93185

I'm really busy working on the lighting so I've left the test patch for a while. There are a couple of small things on my list to add for this test patch but I'm trying to get other things done at the moment.

Thanks, this should now be fixed in Test Patch U6:
https://www.lfs.net/forum/thread/93185

EDIT: Daniel's replay now shows the message "Avoided GEAR_REVERSE" and then goes OOS - which is what should happen.

Test Patch U5:

VR:

FIX: Head tracking / mirrors wrong if car leaned with horizon lock

LAN:

Easier to set up LAN race: local IP address is shown on host screen
You can enter the local network computer name instead of IP address

Misc:

FIX: Rare manual shift at high speed to 1st/rev during auto shift
Most translations updated - thank you translators!

Download:

https://www.lfs.net/forum/thread/93185